1B11 2001 Mini-Project 2

Deadline: Noon Friday 23rd March 2001

Submission: The printed version of your work must be handed in to the departmental office by noon Friday 23rd March 2001 (the last day of term). In addition, a version should be submitted electronically using the handin program (details will be emailed closer to the deadline). Note that the electronically submitted version of your program may be run through an automated plagiarism detector.

With the printed version of your program you must submit an UML class diagram, documenting the classes and their relationships within your program. A hand drawn diagram is entirely acceptable.

Aim: The aim of this mini-project is to write the best and most interesting program you feel able to, putting into practice all that you have learnt so far. Time is limited and there are a number of other courseworks to complete for other courses, so as always plan carefully and make the best use of your time.

Marking: The work will be graded A-F.
On this scheme a grade C is considered to be basically satisfactory which means the program runs, does the more or less the right things and has a reasonable design using classes. Grades B and A represent better and excellent programs, while D and E are progressively less good programs that show serious problems in execution and/or design. Grade F means a failure to present anything of merit.

Getting a good grade: (This advice is the same as for the last mini-project, but it is still good advice!)

All projects require you to write an object-oriented program, making full use of classes, objects and all their associated features. Marking will take into account the quality of the program you write. In particular pay attention to the following:

• Proper declaration and use of classes.
• Proper use of objects.
• The layout and presentation of the program code.
• Appropriate selection of variable and method names.
• Good use of comments to make sure that your code is properly documented.
• Selection of a suitable design to provide an effective solution to the problem in question.

A clean simple working program, making good use of classes and objects, is considered better than a larger and more complex but less well-organised program.

Development Advice:

• Keep things simple!
• Keep things simple! (Very important so I've repeated it.)
• First brainstorm/doodle/sketch to get a feel for the program you need to write and start identifying classes and objects. Typically potential classes can be found by looking for the nouns in the program description.
• Don't rush into writing Java code if you don't fully understand what classes, objects and methods are needed. Don't let the detail of writing code confuse your design thinking.
• Think carefully about objects — what data/state should an object hold, what methods does it need? Use this information to fill out the object's class. Only add instance variables and methods once you see they are really needed.
• How is the behaviour of the program implemented in terms of method calls on objects? Do the objects have the right methods and references to one another?
• Role play or talk through the sequence of method calls between objects to make sure everything makes sense.
• Are your methods short and cohesive? Are your classes cohesive?
• Can't get started? Do a subset of the problem or invent a simpler version, and work on that to see how it goes. Then return to the more complex problem.

The Mini-Projects

Below are listed a small number of mini-project ideas. You must select one.

Q1. Consider the specification for the game below (this is a famous programming competition problem that originated many years ago when OO programming was still fairly new):

The Game of Greed

Greed is a dice game played between two or more players. The object of the game is to tally points from the dice rolls and be the first player to score 5,000 points. There are five dice in the game that are rolled from a cup.

To enter the game, a player must score at least 300 points on the first roll of his or her turn; otherwise, the player is considered “bust”. If the player goes bust, he or she must wait their turn to roll again. If this first roll produces 300 or more points, then the player has the option of stopping and keeping the initial score or continuing. To continue, the player rolls only the dice that have not yet scored in this turn. A player may continue rolling until all the dice have scored or until they go bust. With the exception of the entry roll, a bust is when an individual roll produces no points. The player may stop and keep their score after any roll as long as they have not bust. Each dice roll is tallied as follows:

• Threes of a kind (all the same value) score 100 x face value of one of the three dice.
• If the three of a kind are 1s, then it is scored as 1,000.
• Three 2s = 200 points; three 4s = 400.
• Single 1s and 5s score 100 and 50 points respectively.

Examples (for first roll):

44446 = 400 points
with the option to roll the 4 & 6

11111 = 1000 + 100 + 100 = 1200 points
with the option to role all five dice again

12315 = 100 + 0 + 0 + 100 + 50 points
with the option to roll the 2 & 3

Finally, the winner is determined after a player collects a total score of 5,000 or more and all players have had an equal number of turns. If, for example, a player scores over 5,000 points, they may still lose if a subsequent player ends up with a greater final score.

Implement this game using classes and objects. It is up to you whether you want to include computer players or other more complicated features.

Q2. Remember the simple programs using robots we saw at the start of the course, when learning about the idea of an algorithm? (Or the chess board examples in the text book.) Implement a drawing program that can simulate a robot and use algorithms in order to solve robot-style problems. For example, can you write an algorithm that will move a robot from one corner of a room to the diagonally opposite corner when there are random obstructions in the room? The drawing part of the program can show the robot moving around as the algorithm is followed. Do any of the algorithms shown on the lecture slides actually work?

Q3. Write a program that can parse Java source code, from a number of .java source files, well enough to identify classes, subclass relationships and association relationships, instance variables and methods. Display the results as a simple UML diagram in a drawing program window.

Q4. Don't like any of the other questions? Then invent your own question BUT first email me your idea to get my approval.